Performance counters are any of a variety of functional components/elements within software and hardware used to measure and/or quantify operational characteristics of systems. Though the term “counter” is used extensively herein, performance counters include a broad variety of performance measurement values including ones that are rendered by measurement mechanisms that do not accumulate counted events. For example, a counter value may correspond to an average delay period for carrying out a task. Performance counters are valuable tools in the development and maintenance of properly operating computing systems. Performance counters are relied upon by developers to identify architectural flaws, to verify proper system operation, and to measure throughput. Performance counters are widely used by network/server administrators to monitor/manage the operation of installed systems (e.g., monitoring usage of system resources to identify excessive use of resources and inadequate throughput to meet expected demand).
Performance counters are implemented for a variety of reasons. Performance counters are implemented to measure the effectiveness and capabilities of a system/application under a variety of load conditions. Such information can be used to identify potential/actual problems: system bottlenecks, hacker attacks, needs to re-allocate system resources, etc. Performance counters are also implemented to account for resource usage by particular identified entities. Such accounting can be used to identify particular entities for purposes of billing or merely monitoring usage by particular applications, components, users, etc. Performance counters also facilitate trend analysis by comparing the variations in the measured performance parameters over extended periods of time. In a development environment, performance counters facilitate performing regression analysis (did a change improve/degrade system performance), establishing system capacity (for customer/administrators), and determining whether a particular design goal has been met.
Performance counters also measure a variety of operational parameters. Performance counters measure activity level in the form of percent utilization of resources, disk I/O rates, response times (average), queue length (average), request throughput rate, etc. The performance counters also render measurements of resource usage at various levels of granularity (e.g., per process, per thread, per component, per object). Examples of such provided resource usage measurements include: process working set, thread CPU time, and database cache size. This is merely a small fraction of the virtually limitless number of different measurable parameter types rendered by performance counters.
In one type of performance counter arrangement, a provider/consumer model is adopted that separates performance counter design into two independent and distinct parts. A performance counter provider generates the raw counter information. The performance counter provider for an application containing performance counters, consists of software written specifically for the particular application with which it is associated. In a particular known performance counter provider/consumer arrangement, discussed herein below with reference to FIG. 2, a performance counter dynamically linked library (hereinafter “dll”) is written specifically for a particular counter provider. The performance dll communicates with the application providing the raw counter data via inter-process communications.
A performance counter consumer, as the name suggests, receives and processes the raw performance counter data provided by the provider and presents it to a user. In the known performance counter architecture described herein below with reference to FIG. 2, the counter consumer accesses the raw performance counter data, which is rendered by the counter provider, via the performance dll. An example of a performance counter consumer is MICROSOFT WINDOWS Performance Monitor utility. When the counter consumer needs a particular performance counter, the consumer loads the performance dll and then calls an entry point into the dll. In response an inter-process communication link, such as shared memory, is established between the dll and the counter provider. A name is assigned to the shared memory by the provider's application and performance DLL. The provider places counter information within the shared memory location and the consumer retrieves the counter information via the dll using the shared memory. The dll, in response to requests from the consumer, retrieves the counter data from the shared memory, adds metadata to facilitate interpretation of the counter data by the consumer, and returns the data to the requesting consumer.
This prior arrangement for providing performance counters places responsibility for providing counters in the hands of provider authors. This approach presents a number of potential drawbacks. For example, the potential for name space conflicts exists. In particular, the performance dll may use a name that has been previously claimed. In that case, operation of the dll is blocked by the previous claimant of the shared memory name. As a consequence, the reliability of performance counters operating according to the performance dll approach is called into question.